![SORACOM Napter で複数ネットワーク接続をもつ Raspberry Pi 3 にオンデマンドリモートアクセス](https://devio2023-media.developers.io/wp-content/uploads/2020/02/soracom-logo.png)
SORACOM Napter で複数ネットワーク接続をもつ Raspberry Pi 3 にオンデマンドリモートアクセス
こんにちは、菊池です。
IoTデバイスへのオンデマンドでのリモートアクセスを提供するサービスSORACOM Napterを使って、Raspberry Pi 3へのSSHアクセスを試してみました。
SORACOM Napterについては非常にシンプルで特に迷う部分もありませんでしたが、接続先のRaspberry Pi 3がSORACOM Air SIM以外のローカルネットワークにも接続していたため、デバイス内でのルーティング設定が必要でした。
接続構成
接続構成は以下の通り。
- IoTデバイス
- Raspberry Pi 3 Model B
- LTEドングル docomo L-02A
- SORACOM IoT SIM
- 特定地域向けSIM plan-D
SORACOM Napterのリモート接続
オンデマンドリモートアクセス
まずはデバイス側でppp接続を行い、SIMのステータスがオンラインであることを確認します。コンソールから、対象のSIMを選び、[操作]を選択します。
メニューから[オンデマンドリモートアクセス]を選択しましょう。
デバイス側のポートとアクセス可能な時間、アクセス元のIPを選びます。なお、SORACOM Napterは特定地域向けで1SIMあたり300 円/月の利用料が発生しますが、1アカウント1月1SIMまでの無料枠があります。
すると、接続用のIPアドレスとポートが表示されます。このIP/ポートにてSSH接続を試します。
リモート接続
ここで、ちょっと問題が発生しました。指示通りに接続しても一切レスポンスがない状態となっていました。
$ ssh -p xxxxx skikuchi@3.xxx.xxx.xxx
SORACOM Napterには特に他に設定する項目もないのでしばらく悩みましたが、Raspberry Pi 3側のルートテーブルに問題があることに気がつきました。
今回利用したRaspberry Pi 3は、IoT SIM以外に、EthernetでローカルのネットワークにスタティックIPで接続していました。
$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:6f:c1:e5 brd ff:ff:ff:ff:ff:ff inet 192.168.99.238/24 brd 192.168.99.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::def6:f5f1:baed:60aa/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether b8:27:eb:3a:94:b0 brd ff:ff:ff:ff:ff:ff 4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3 link/ppp inet 10.215.166.57 peer 10.64.64.64/32 scope global ppp0 valid_lft forever preferred_lft forever
Ethernet側にデフォルトルートを設定していましたので、ルートテーブルを確認すると以下のようになっていました。
$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.99.254 0.0.0.0 UG 202 0 0 eth0 10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.99.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
デフォルトルートがeth0側を向いているため、ppp0からのSSHアクセスに対するレスポンスが正しく返せていないようです。Napterからアクセスしてくるソースアドレスがわからないので、とりあえず、eth0側より小さいメトリックでデフォルトルートを追加しました。
$ sudo ip route add 0.0.0.0/0 via 10.64.64.64 metric 100 dev ppp0
これでルートテーブルは以下のようになりました。
$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 10.64.64.64 0.0.0.0 UG 100 0 0 ppp0 default 192.168.99.254 0.0.0.0 UG 202 0 0 eth0 10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.99.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
これで再度、Napterのリモートアクセスを試した結果、ようやくSSH接続ができました。
$ ssh -p xxxxx skikuchi@3.xxx.xxx.xxx : : skikuchi@3.xxx.xxx.xxx's password: : : Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri Feb 7 14:20:01 2020 from xxx.xxx.xxx.xxx $
Napterでのリモートアクセスはできましたが、このままでは、デフォルトルートとして常時SORACOM IoT SIM側を利用してしまうため、必要な宛先の範囲だけIoT SIMを使うようにします。まず、NapterでログインしてきているIPアドレスを確認します。
$ w -i 14:51:11 up 34 min, 3 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT skikuchi pts/0 100.127.10.16 14:50 2.00s 0.21s 0.03s w -i
どうやら、Napterでオンデマンドリモートアクセスする際のアクセス元IPは、デバイスから見ると100.68.0.0/10の範囲(RFC6598)となってそうです。改めてルートテーブルを以下のように設定しました。
$ sudo ip route add 100.64.0.0/10 via 10.64.64.64 metric 100 dev ppp0 $ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.99.254 0.0.0.0 UG 202 0 0 eth0 10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 100.64.0.0 10.64.64.64 255.192.0.0 UG 100 0 0 ppp0 192.168.99.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
これで再度、Napter経由でのSSHを確認したところ、問題なく接続ができました。
まとめ
SORAOM Napterによるオンデマンドリモートアクセスを試しました。IoT SIMにさえ接続できていれば、必要に応じでリモートから簡単にアクセスが可能です。一方で、複数のネットワークに接続するデバイスの場合には、デバイスのルートテーブルを要確認という話でした。